Реализация gRPC-метода LogoutUser в auth-service

Разработка обработчика LogoutUser, инвалидация Access-токена в Redis и отзыв сессии в PostgreSQL.

Author

Services Task & Simulation Framework Documentation

Published

July 13, 2026

NoteКраткая карточка задачи
  • Репозиторий / Компонент: auth-service (Внутренний контур авторизации).
  • Контракт методов: gRPC rpc LogoutUser(LogoutRequest) returns (LogoutResponse);
  • Спецификация контракта: См. Раздел: Protobuf Контракт
  • Статус: Готово к реализации
WarningОграничение публичной документации

В открытом доступе представлена демонстрационная версия задачи. В настоящей публичной документации отображены не все шаги, технические сценарии и приватные эндпоинты для системы цифровых симуляторов бизнес-процессов.

  • Полная спецификация метода: Доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).
  • Для получения доступа: Обратитесь к системному аналитику или Product Owner вашей команды.

  • Предварительные условия (Prerequisites):

    1. Перед началом разработки убедиться, что структура Protobuf-сообщения перенесена в репозиторий контрактов строго в соответствии со Спецификацией Protobuf.
    2. Сгенерировать серверные стабы (gRPC stubs) для целевого языка компонента auth-service.

  • Инструкция по шагам:

    1. На Шаге 3 (Прием запроса и валидация): Реализовать gRPC-обработчик для метода LogoutUser. Обеспечить строгое чтение параметров refresh_token и user_id из входящего Protobuf-сообщения LogoutRequest. Если хотя бы одно из полей отсутствует или передано в невалидном формате, прерывать выполнение и возвращать статус-код gRPC Status: INVALID_ARGUMENT.

    2. На Шаге 4 (Инвалидация через Блэклист): Внутри обработчика разобрать метаданные сессии и вычислить оставшееся время жизни (Remaining TTL) для соответствующего Access-токена. Выполнить команду внесения токена в распределенный кэш блокировок Redis: SET "blacklist:access:<access_token_hash>" "revoked" EX <Remaining_TTL>.

    3. Перехват исключений (Fail-Close): Завернуть операцию записи в Redis в блок обработки исключений. При падении кэша или сетевом таймауте (Redis.ConnectionError, Redis.TimeoutError), задействовать стратегию Fail-Close: принудительно прерывать транзакцию, логировать критический сбой системы и возвращать вызывающей стороне ошибку, которая на шлюзе трансформируется в логический бизнес-статус HTTP 503 Service Unavailable.

    4. На Шаге 6 (Деактивация в СУБД): При успешной фиксации токена в Redis, инициировать транзакцию в PostgreSQL (DB_AUTH).

      Выполнить SQL-запрос на закрытие сессии:

      UPDATE user_sessions SET is_revoked = true 
WHERE refresh_token_hash = :refresh_token_hash AND user_id = :user_id;

      Если СУБД возвращает статус UPDATE 0 (запись не найдена), генерировать внутренний логический ответ “Сессия не найдена”. При успешном обновлении строки сформировать и вернуть gRPC-ответ LogoutResponse с флагом success: true.